Read() causing Exception error

SystemAdmin - Thu Sep 16 08:32:43 EDT 2010
Is the module to which mn refers to deleted? Or is the mn reference null? Are you checking for these?

sdauphin - Thu Sep 16 09:03:29 EDT 2010

@Pekka :
No, I am not checking these points.

This is the entire loop code :

// for each link arriving on o and following rlm link module
        for lref in o <- "rlm" do {
                        // Get the source module name
                        mn = source(lref)
                        // opens the module in read mode and invisible if it is not open
                        if(!open(mn)) {
                                read(fullName(mn),false)
                        }
                }

I am just trying to open all the modules containing objects that are linked to current object o by incoming links.

In the tests I am doing, the linked modules are not deleted. Should I add some checks in this context ?

Mathias Mamsch - Thu Sep 16 09:45:00 EDT 2010
When your code crashes that usually means, that one variable contains invalid data. Sometimes your code crashes, because you did something to corrupt your memory a few lines above, but the crash occurs later, when you access the corrupt memory. For your code a typical way to make the code crash is to close or change the edit modue of the module that contains the object o.

For me there are two plausible reasons that your code crashes with an exception:
a) Your ModName_ variable memory got corrupted (Could not see how or why? Eventually by really messing up the DOORS heap)
b) Your Object variable memory got corrupted (more plausible, maybe the module is closed, or the edit mode changed?)

You probably did this in some part of the code, that you have not posted, or at least I could not spot a reason. In most cases it is so hard to find bugs, since we look at the wrong place. Can you post a more complete code example?

Regards, Mathias

sdauphin - Thu Sep 16 10:57:26 EDT 2010
Mathias,

I am attaching the full script as a zip file (~ 600 lines). There is a small readme file, I hope it contains enough information.

The extract is coming from function initLinkedObjectList in objectModified.dxl, but if I understand you well, the root cause of the problem may be anywhere, right ?

I hope you can point me to weak code statements.

Best regards,

Servanne.

Mathias Mamsch - Thu Sep 16 12:14:36 EDT 2010

Two things come to my eye when skimming through your code:

1. ... Link deletion in loop ... objectModified.dxl:144

for l in o1 -> rlmn do {
    delete(l) 
}

Don't do that. Always use

Skip sk = create(); for l in o1->rlmn do { put (sk, l,l) }; for l in sk do delete l

Since deletions that modify the loop object most of the times brings DOORS to its knees and might be responsible for heap corruption.

2. When I recognize the crash code right it should be objectModified.dxl:304. I checked the caller and found:

objectModified.dxl:280 -> void initLinkedObjectList (DBE listDBE, Object o)
...
objectModified.dxl:280 -> for lref in o <- fullName(rlm) do {
...
objectModified.dxl:300 -> mn = source(lref)
objectModified.dxl:304 -> if(!open(mn))
objectModified.dxl:305 -> m = read(fullName(mn),false) // boom!

...
objectModified.dxl:389 -> if(src_obj_is_new){
objectModified.dxl:391 -> saveObject(src_obj)
objectModified.dxl:392 -> }
...
objectModified.dxl:409 -> initLinkedObjectList (listDBE, src_obj)

{code}

saveObject(src_obj) does a unlockSaveSection src_obj. My guess is, that this invalidates the object handle, which you will only see once the object memory is reused by something other. Can you comment out the saveObject and check if the error disappears?

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Mathias Mamsch - Thu Sep 16 12:14:36 EDT 2010

Two things come to my eye when skimming through your code:

1. ... Link deletion in loop ... objectModified.dxl:144

for l in o1 -> rlmn do {
    delete(l) 
}

Don't do that. Always use

Skip sk = create(); for l in o1->rlmn do { put (sk, l,l) }; for l in sk do delete l

Since deletions that modify the loop object most of the times brings DOORS to its knees and might be responsible for heap corruption.

2. When I recognize the crash code right it should be objectModified.dxl:304. I checked the caller and found:

objectModified.dxl:280 -> void initLinkedObjectList (DBE listDBE, Object o)
...
objectModified.dxl:280 -> for lref in o <- fullName(rlm) do {
...
objectModified.dxl:300 -> mn = source(lref)
objectModified.dxl:304 -> if(!open(mn))
objectModified.dxl:305 -> m = read(fullName(mn),false) // boom!

...
objectModified.dxl:389 -> if(src_obj_is_new){
objectModified.dxl:391 -> saveObject(src_obj)
objectModified.dxl:392 -> }
...
objectModified.dxl:409 -> initLinkedObjectList (listDBE, src_obj)

{code}

saveObject(src_obj) does a unlockSaveSection src_obj. My guess is, that this invalidates the object handle, which you will only see once the object memory is reused by something other. Can you comment out the saveObject and check if the error disappears?

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

sdauphin - Thu Sep 16 09:03:29 EDT 2010

@Pekka :
No, I am not checking these points.

This is the entire loop code :

// for each link arriving on o and following rlm link module
        for lref in o <- "rlm" do {
                        // Get the source module name
                        mn = source(lref)
                        // opens the module in read mode and invisible if it is not open
                        if(!open(mn)) {
                                read(fullName(mn),false)
                        }
                }

I am just trying to open all the modules containing objects that are linked to current object o by incoming links.

In the tests I am doing, the linked modules are not deleted. Should I add some checks in this context ?

llandale - Thu Sep 16 13:11:46 EDT 2010
Mathias is probably right.

But its possible the default view in that module has layout code that causes the crash. Before you "read", ack the fullname. When you find out which module triggers the crash, try opening it first manually then via a DXL read statement. You may also want to split the fullname up from the read: Name = fullName(mn).

If there is an issue with the view, you can bypass it with:
read(fullName(mn), false, true)
which loads the 'standard' view.

• Louie

sdauphin - Thu Sep 16 14:07:40 EDT 2010
Hello,

I have tried the different suggestions :

• deletion of links
• comment out saveObject function calls
• use read(fullName(mn), false, true)

• Open exclusive the pool module. The other modules are closed.
• point on an existing object with 3 incoming links : 2 from project-module #1, 1 from project-module #2.
• modify the Object text of this object.
• the trigger fires and I get the dialog box with the list of 3 linked objects.
• I select them all and click apply.
• the synchronization goes well, and I get the success message box.
• Then, I try to redo the same steps : I modify the Object Text of the same object, the trigger fires and DOORS crashes with an exception access error message on the read statement.

sdauphin - Fri Sep 17 05:48:51 EDT 2010

I have made some progress this morning :

I replaced these statements (in synchronizeOrReplace function):

objects_to_synchronize_skip = linked_objects_skip
modules_to_synchronize_skip = linked_modules_skip

by this piece of code :

int i = 0
        Object temp_o
                for temp_o in linked_objects_skip do {
                        put (objects_to_synchronize_skip, i++, temp_o)
                }
                i = 0
                ModName_ tmod
                for tmod in linked_modules_skip do {
                        put (modules_to_synchronize_skip, i++, tmod)
                }

Now the script is much more stable, but I was still getting some crashes.

So, I commented out the calls to closeInvisibleModules function, and since then, I didn't get any crash when the script was running, but only when closing the pool module.

Could you have a look at that function (in tools.dxl) ? Is it closing more files than required ? How would you implement it ?

Best regards,

Servanne.

sdauphin - Fri Sep 17 05:51:22 EDT 2010

I'm posting the code here for more convenience :

/**
* Closes all the modules opened by a script, so which are not visible.
*/
void closeInvisibleModules(){
    Module m
        // for each open module in the database (with read access from the current user)
        for m in database do {
                // if m is a formal module and is not visible, close it
                if(type(m)=="Formal" && !isVisible(m)) close(m,false)         
        }
}

sdauphin - Fri Sep 17 05:48:51 EDT 2010

I have made some progress this morning :

I replaced these statements (in synchronizeOrReplace function):

objects_to_synchronize_skip = linked_objects_skip
modules_to_synchronize_skip = linked_modules_skip

by this piece of code :

int i = 0
        Object temp_o
                for temp_o in linked_objects_skip do {
                        put (objects_to_synchronize_skip, i++, temp_o)
                }
                i = 0
                ModName_ tmod
                for tmod in linked_modules_skip do {
                        put (modules_to_synchronize_skip, i++, tmod)
                }

Now the script is much more stable, but I was still getting some crashes.

So, I commented out the calls to closeInvisibleModules function, and since then, I didn't get any crash when the script was running, but only when closing the pool module.

Could you have a look at that function (in tools.dxl) ? Is it closing more files than required ? How would you implement it ?

Best regards,

Servanne.